Configurable backend and per-solve scratch allocator - #467

The local updates of an MPS algorithm allocate a fair number of intermediates,
all of which die before the next update. Serving them from an allocator rather
than from Julia's memory manager keeps them out of the garbage collector's way.

Which allocator is appropriate depends on where the tensors live and on whether
more than one task will be sharing it, neither of which is a property of the
algorithm: `default_allocator(x, scheduler)` is therefore asked at the start of a
solve, and the answer used for all of its local updates. Host memory gets a
`BufferAllocator` when a single task owns it and a `ManualAllocator` when it is
shared; any other storage type falls back on `DefaultAllocator`, which allocates
through the storage type itself and is therefore correct on any device.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The effective local operators now carry the backend and allocator their matvec
should use, and their constructors and `prepare_operator!!` accept them. This is
what lets a single reused buffer capture all of the intermediates of the
effective-Hamiltonian applications across an entire sweep.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The bond-expansion algorithms grow a `backend` field and thread it, together with
an allocator, through their contractions. `changebond!` and `gauge!` take them as
keyword arguments, so a `DMRG`/`TDVP` sweep can hand its own down into the
expansion and gauge steps rather than each step picking its own.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`DMRG`/`DMRG2` grow a `backend` field, and the sweep asks `default_allocator` once
for a serial allocator that then serves every local update: a single buffer
captures the effective-operator intermediates of the whole sweep. On a spin-1
Heisenberg chain (L=100, chi=128) this cuts allocations by 64%, garbage-collection
time by 57% and wall time by 23%, at an unchanged ground-state energy.

`IDMRG`/`IDMRG2` and the `approximate` variants get the same treatment.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Both integrators grow a `backend` field. The finite sweeps take a single serial
allocator for all of their local updates; for the infinite `TDVP` the scheduler is
read once at the entry point, so that the allocator it selects -- a buffer when
serial, a manual allocator when the sites are spawned concurrently -- is
inferable, and the AC and C sweeps share it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Both grow a `backend` field, and their unit-cell sweeps take the allocator
matching the scheduler they spawn with.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`fg` takes the backend and the scheduler as keyword arguments rather than reading
the scheduler itself, so the allocator it selects matches the concurrency of the
gradient it is computing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`ChepigaAnsatz2`, `FiniteExcited`, `exact_diagonalization` and the dynamical-DMRG
propagator grow a configurable backend and draw their local-update scratch space
from an allocator, as the other algorithms now do.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Document why the allocator is asked for per solve rather than configured on the
algorithm: it depends on where the tensors live and on whether it will be shared
between tasks, and neither is known to the algorithm. Also note that `backend`
needs no such treatment, since `DefaultBackend` already resolves to cuTENSOR for
`CuArray`-backed states.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…orithms

`test/misc/allocator.jl` covers `default_allocator` itself: the host/device split,
the serial-vs-shared choice and the buffering preference. `test/algorithms/allocator.jl`
checks that the algorithms give the same answers with and without a buffer, and
`test/gpu/*/algorithms.jl` runs a shared set of algorithms on device-backed states,
which is what pins down that the device path stays on `DefaultAllocator`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Same treatment as the other integrators: a `backend` field, and a single serial
allocator obtained once per `timestep!` that serves the effective-Hamiltonian
application of every local update. The bond cut and the basis augmentation are
factorizations rather than effective-operator contractions, so -- as with a plain
`gauge!` -- there is nothing to route to them.

Measured on a spin-1 Heisenberg chain (L=20, chi=48), one BUG step allocates
792 MiB with the buffer against 886 MiB without it; the smaller relative gain than
TDVP's (325 against 513 MiB) is because BUG spends more of its time in the
augmentation step, which the allocator does not serve.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ctions

`ProjectionDerivativeOperator` was the one derivative operator whose matvec still
contracted with a bare `@plansor`, so the Galerkin error and the `FiniteExcited`
eigensolves left their intermediates to the garbage collector even when the sweep
was holding a buffer. It now carries the backend and allocator like the others do,
and the constructors pass them in.

Reported by @borisdevos in review of #467.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`localupdate_step!` asked `default_allocator` on every outer iteration, so each
sweep grew a fresh buffer from empty and dropped it again -- the opposite of the
reuse the buffer exists for. The allocator now lives on `IDMRGState`, next to the
timer output, obtained once when the solve starts and carried along; the initial
Galerkin error uses it too.

Reported by @borisdevos in review of #467.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`Bk <: AbstractBackend`, as `MPODerivativeOperator` and `PrecomputedDerivative`
already have it. This buys nothing from the compiler -- Julia specializes on the
field type either way -- but it does give an explicit error rather than a late
`MethodError` if something that is not a backend ends up in that field.

Suggested by @borisdevos in review of #467.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`test/setup/gpu_algorithms.jl` reached for `TensorOperations` directly, which is not a
test dependency, so the CUDA/AMDGPU algorithm tests errored on load. Take the
allocator types from MPSKit, as `test/misc/allocator.jl` already does.

While here, run the device timestep for `BUG` as well as `TDVP`. Verified on an
RTX A6000: 19/19 pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`changebond!` obtained a fresh allocator on every call, i.e. once per site: with
CBE the buffer was rebuilt and thrown away at every local update, which is the
opposite of what it is for. It now takes the allocator as a keyword argument,
defaulting to one of its own so that a standalone `changebonds!` still works, and
the `DMRG`/`TDVP` sweeps pass the one they are already holding. `RandExpand` has no
effective-operator contraction to serve, so it accepts and drops it, as a plain
`gauge!` does.

Measured on a spin-1 Heisenberg chain (L=30, expand 8, truncate to 48), two
CBE-DMRG sweeps allocate 1170 MiB against 1263 MiB before.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`test/algorithms/allocator.jl` re-ran DMRG, DMRG2, TDVP, BUG, CBE, IDMRG and
changebonds that the algorithm suites already cover. Only two claims were actually
new, and they now live next to the tests they belong to:

- re-using one algorithm object across solves reproduces the answer (it carries no
  scratch space of its own), in the finite `DMRG` and `timestep` testsets;
- the scheduler choice -- which is what decides between a buffer and a shared
  manual allocator -- changes no number, by parametrizing the existing infinite
  `VUMPS`, `GradientGrassmann` and `Infinite TDVP` testsets over both.

`with_scheduler` and the serial/dynamic pair move to `TestSetup`, so there is one
failure-safe implementation instead of the ad-hoc `set_scheduler!` save/restore
`approximate.jl` was doing. `MPSKit.Defaults.scheduler` is a `Ref` rather than a
`ScopedValue`, hence the explicit restore.

The hand-rolled inference helpers are gone in favour of `@testinferred`; the one
remaining `return_type` call is the abstract-signature case, which no call-based
macro can express, and matches how `src/` already spells it.

The GPU file keeps only what a device can prove -- that a device-backed state is
never handed a host allocator -- and drops the `find_groundstate`/`timestep` runs,
which duplicated CPU coverage. Renamed to `allocator.jl` accordingly, since it no
longer tests algorithms.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…testsets

With two loop variables the `@testset for` body is a single scope for all
iterations, so binding the starting state to `ψ` fed the previous iteration's
result back into `repeat(ψ, unit_cell_size)`: the second scheduler arm at unit
cell 3 got a length-9 state against a length-3 Hamiltonian ("lengths must match").

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>